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(57) A system and method for providing secure data 
communications and user access authorization for an 
integrated emergency medical transportation database 
(12). The secure communications and user authorization 
may be provided, for example, by a Virtual Private Net- 
work ("VPN") (220), as well as alternate methods and 
systems described herein, allowing confidential patient 
medical records to be transmitted via a public network 
(50) such as the I nternet without compromising the con- 
fidentiality of the data. 
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Description 

Field of the Invention 

[0Q01] This invention relates to an integrated medical 5 
database system. More specifically, this invention relates 
to providing secure communications and user authoriza- 
tion for a medical database in the emergency medical 
transportation industry. 

10 

Description of the Related Technology 

[0002] Current documentation procedures in the air 
medical transport industry are based on an inefficient pa- 
per and pencil technology. Important information is fre- 15 
quently collected on loose sheets of paper. In the envi- 
ronment of emergency medical transport, little time is 
available to neatly chart and document all pertinent and 
required information on a single document. Dispatch da- 
ta, demographic data and clinical data are normally 20 
tracked as fragmented pieces of information, which are 
later coalesced into a complete patient chart. In many 
cases, these data include the same information, thus 
forcing the input of redundant information. The resultant 
chart is therefore vulnerable to being incomplete and un- 25 
reliable. In a medical setting, incomplete information can 
lead to disastrous clinical results. 
[0003] This same technology is used to support indus- 
try quality improvement and billing procedures and sub- 
mit letters of trans port justification. This paperwork is usu- 30 
ally carried out at a later date, prolonging account receiv- 
able times in many instances to the point of compromising 
and jeopardizing service compensation. Inventory stock- 
ing and tracking is similarly a victim of extended turnover 
times and is often incomplete and inaccurate. 35 
[0004] The fragmentation throughout the medical 
transport environment is also evident in the myriad of 
entities throughout the country practicing different stand- 
ards of care and documentation. As is the case in other 
segments of the healthcare industry, even seemingly 40 
simple tasks of communicating among the various enti- 
ties, as well as among sections of a single providing en- 
tity, is severely hampered by the lack of a common com- 
munication format. This is especially evident when cer- 
tain aspects of the system (such as computerized clinical 45 
laboratory result displays) have been upgraded with a 
uniquelytailored computerized system, whilethe remain- 
ing functions are still performed in an archaic manner. 
While the upgraded system may be effective for one sin- 
gular aspect, such as dispatching, lab reporting, or chart 50 
dictating, the remainder of the system does not improve 
its effectiveness due to the other archaic components. 
[0005] In addition, current air medical transport serv- 
ices often transfer data in unsecure protocols and over 
unsecure publiccommunication paths, and do not always 55 
validate users as being authorized users. Thus, current 
systems are susceptible to unauthorized users gaining 
access to the system and thereby compromising the in- 



tegrity and confidentiality of the stored data, as well as 
the interception or corruption of data in transit via public 
communications networks, for example the Internet. 
[0006] Therefore, a comprehensive system exists that 
includes modules for dispatching emergency medical 
teams, tracking their movement to and from the accident 
scene, managing a clinical diagnosis and treatment and 
accurately billing the patient for the services rendered. 
Such asystem should optionally incorporate security and 
user authorization measures to ensure the integrity and 
confidentiality of the data that is transferred over public 
communications networks and data that is stored by the 
system. The system should also comply with applicable 
governmental regulations and guidelines, for example 
the European Standards on Confidentiality and Privacy 
in Healthcare (this Guidance was published in 2006), and 
future versions of these or other regulations. 

Summary of Certain Inventive Aspects 

[0007] In one aspect, a secure integrated emergency 
medical transportation database system includes a med- 
ical emergency database including at least clinical en- 
counter information, patient demographic data and trans- 
port information as electronic protected health informa- 
tion, a billing module configured to access the medical 
emergency database and generate a bill for each medical 
emergency requiring transport, and a secure communi- 
cations application configured to allow secure access to 
the medical emergency database and/or billing module 
by a plurality of authorized users via a public network, 
wherein the secure access comprises technical security 
measures to protect against unauthorized access to the 
electronic protected health information during transmis- 
sion over the public network so that data indicative of a 
medical emergency is securely stored in the medical 
emergency database from a location in the field that is 
remote from a health service facility. 
[0008] Further embodiments of the system may in- 
clude the following features. The secure communications 
application may be additionally configured to allow the 
secure transfer of medical data via the public network. 
The secure access may be compliant with the European 
Standards on Confidentiality and Privacy in Healthcare. 
The secure access may protect against a risk of inter- 
ception during electronic transmission of the health in- 
formation. The secure access may be compliant with Eu- 
ropean Union patient privacy standards. The secure 
communications application may secure communica- 
tions via the public network. The secure communications 
application may use secure sockets layer. The secure 
communications application may include a virtual private 
network. The secure communications application may 
include encryption and decryption algorithms. The se- 
cure communications application may include encryption 
and decryption keys. The secure communications appli- 
cation may authenticate validity of a one of the plurality 
of authorized users. The secure communications appli- 
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cation may include a dedicated, secure and encrypted 
channel. The transport information may include informa- 
tion obtained about the transport after first contact by 
medical transport personnel. The transport information 
may be associated with the clinical encounter information 
by at least patient pickup data. The system may addition- 
ally a portable computing device used by emergency 
medical personnel to wirelessly access a public network 
in real time while at the patient pick-up location or during 
a transport of an emergency medical services patient, 
and in further embodiments the secure communication 
application may be associated with the computing de- 
vice, and the portable computing device may be used by 
emergency medical personnel inside an emergency 
transport vehicle. The transport information may include 
vehicle tracking information including segmental flight 
time for each transport segment. The technical security 
measures may minimize access to inappropriate infor- 
mation based on job requirements. The field location may 
be at a location between two health service facilities that 
are the source and destination of the transport. 
[0009] In another aspect, a method of providing access 
to a secure integrated emergency medical transportation 
database system includes collecting at least clinical en- 
counter information, patient demographic data and trans- 
port information as electronic protected health informa- 
tion foreach of a plurality of medical emergency incidents 
requiring transport into a medical emergency database, 
accessing the medical emergency database, generating 
a bill for each medical emergency incident accessed, and 
securing access to the medical emergency database 
and/or billing information by a plurality of authorized us- 
ers via a public network, where securing access com- 
prises using technical security measures to protect 
against unauthorized access to electronic protected 
health information during transmission over the public 
network so that data indicative of a medical emergency 
is securely stored in the medical emergency database 
from a location in the field that is remote from a health 
service facility. 

[0010] Further embodiments of the method may in- 
clude the following features. The method may also in- 
clude securing the transfer of medical data via the public 
network. Securing access may be compliant with the Eu- 
ropean Standards on Confidentiality and Privacy in 
Healthcare. Securing access may include protecting 
against a risk of interception during electronic transmis- 
sion of the health information. Securing access may be 
compliant with European Union patient privacy stand- 
ards. Securing access may include securing communi- 
cations via the public network. Securing access may in- 
clude using secure sockets layer. Securing access may 
include using a virtual private network. Securing access 
may include using encryption and decryption algorithms. 
Securing access may include using encryption and de- 
cryption keys. Securing access may include authenticat- 
ing validity of a one of the plurality of authorized users. 
Securing access may include using a dedicated, secure 



and encrypted channel. The transport information may 
include patient pickup data and secmental f lighttime, and 
may be used for billing. The collecting may include wire- 
lessly collecting the electronic protected health informa- 

5 tion by emergency medical personnel via a public net- 
work while atthe scene of the patient encounter or during 
transport of an emergency medical services patient, and 
the wirelessly collecting may include using a portable 
computing device inside an emergencytransport vehicle. 

10 The transport information may include vehicle tracking 
information including segmental flight timeforeach trans- 
port segment. The field location may be at a location be- 
tween two health service facilities that are the source and 
destination of the transport. 

15 

Brief Description of the Drawings 

[001 1 ] The above and other aspects, features and ad- 
vantages of the invention will be better understood by 

20 referring to the following detailed description, which 
should be read in conjunction with the accompanying 
drawings. These drawings and the associated descrip- 
tion are provided to illustrate certain embodiments of the 
invention, and not to limit the scope of the invention. 

25 [0012] Figure 1 is a diagram of an on-line computing 
environment of a medical database system in which a 
Virtual Private Network ("VPN") may operate in accord- 
ance with one embodiment of the present invention. 
[0013] Figure 2 is a diagram of top-level VPN system 

30 components in accordance with one embodiment of the 
medical database system of Figure 1 . 
[0014] Figure 3 is a diagram of detailed VPN system 
components in accordance with the medical database 
system embodiment of Figures 1 and 2. 

35 [0015] Figure 4 is a block diagram of client applications 
of the user device, VPN server, and terminal server com- 
ponents as shown in the embodiment of Figure 3. 
[001 6] Figure 5 is a flowchart of database access op- 
erations of the medical database system in accordance 

40 with the embodiments of Figures 1-3. 

[0017] Figure 6 is a diagram of one example of a da- 
tabase configuration layout in accordance with one em- 
bodiment of the medical database system. 

45 Detailed Description of Certain Embodiments 

[001 8] Thefollowing detailed description of certain em- 
bodiments presents various descriptions of specific em- 
bodiments of the present invention. However, the present 

50 invention can be embodied in a multitude of different 
ways as defined and covered by the claims. In this de- 
scription, reference is made to the drawings wherein like 
parts are designated with like numerals throughout. 
[0019] In certain embodiments, the present invention 

55 relates to an object oriented, interactive, international, 
client-server service for the medical transport industry. 
The service may integrate all aspects of patient record 
documentation into a single complete electronic chart. A 
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server computer provides chart database information ac- 
cess to multiple transport providers simultaneously by 
securely transmitting, storing and maintaining standard- 
ized patient data, for instance, using guidelines set forth 
by the Scrambling Standards Organization. Individual 
transport-providing entities, such as helicopter and am- 
bulance companies, obtain coded access to this server 
via phone lines with a modem-equipped personal com- 
puter. Security is maintained by assigning each entity a 
unique code or identifier. Integrated Services Digital Net- 
work ("ISDN") lines, Digital Satellite Systems ("DSS"), 
dedicated trunk lines (for example T1 , T3), cable mo- 
dems, digital subscriber lines ("DSL"), or digital wireless 
systems may also be used for communication. Such an 
emergency medical transportation database system is 
described in U.S. Patent No. 6,1 17,073, which is hereby 
incorporated by reference in its entirety. 
[0020] Each crew member involved in the patient's 
chart documentation, i.e. dispatcher, flight nurse, para- 
medic and physician, as well as administrator and col- 
lector, possess coded access to chart portions relevant 
to their responsibilities and level of care provided. The 
chart is then electronically generated from the compen- 
dium of the information entered in a standardized fashion 
and in accordance with minimum industry documentation 
requirements and the inventory of financial health care 
standards. The system provides complete and accurate 
chart documentation and maintains internal consistency 
between each separate module. Furthermore, any sen- 
tinel events are automatically referred to the appropriate, 
responsible party. A sentinel event is any action during 
the encounter that might require a further review. Exam- 
ples of sentinel events are scene times exceeding 40 
minutes, nonsensical data entry by an emergency trans- 
port crew member, supply shortages for equipment not 
utilized or repeated claim denials. 
[0021] Billing can be submitted electronically to the ap- 
propriate party in an appropriate format that reduces the 
accounts receivable times for each patient encounter. 
Letters of justification are automatically generated as well 
as follow up letters and utilization review reports. Inven- 
tory reports and lists of necessary base supplies and 
medicines are also electronically updated to appropriate 
supply centers and administrators. Customized and re- 
search reports can also be provided rapidly. 
[0022] Data security and an automatic backup are pro- 
vided. Although the chart data is normally madethe prop- 
erty of the respective transport service provider, the sys- 
tem can retain non-proprietary data to provide industry 
benchmarking, quality assurance analysis and clinical re- 
search opportunities. Such standardized data collection 
and documentation will furthermore enable the develop- 
ment of an Emergency Medical Services data library to 
assist in the justification and legislation of governmental 
preventive policies for public safety. 
[0023] The communication of data via a public network 
would normally be susceptible to being intercepted by 
unauthorized users. In the medical transportation sys- 



tem, data communicated via the public network may in- 
clude confidential information such as patient medical 
records. The present invention includes a Virtual Private 
Network ("VPN") operating on the public network to en- 

5 sure confidentiality of the patient data. A system accord- 
ing to the present invention complies with applicable reg- 
ulations regarding the confidentiality of patient data, for 
example the European Standards on Confidentiality and 
Privacy in Healthcare, or other European Union patient 

10 privacy standards. The VPN of the emergency medical 
transportation system may be thought of in terms of a 
three-tier architecture: 1) the user, 2) the business rules 
processing, and 3) the database. 
[0024] Figure 1 provides an overview of the computer 

15 hardware involved in one embodiment of a medical da- 
tabase system 1 00. In this embodiment, the medical da- 
tabase system 100 includes a server computer 12. The 
server computer 12 can be based on many microproc- 
essors, such as those manufactured by Intel, Motorola, 

20 IBM or other chip manufacturers. The server computer 
1 2 enables rapid simultaneous access to many users of 
the system. In one embodiment, the server computer 1 2 
is an Intel Pentium III class computer having at least 256 
Megabytes of RAM and a 10 gigabyte hard disk drive 

25 and a 500 megahertz ("MHz") processing speed. In ad- 
dition, many other standard or non-standard computers 
may support various embodiments of the medical data- 
base system 1 00. 

[0025] The database application may be programmed 

30 in, for instance, ACIUS's 4th Dimension language and 
used in conjunction with the 4D Server and Client pro- 
gram. Also, another alternative computer environment is 
Microsoft Corporation's Visual Basic language with C++ 
middleware and the BackOffice SQL Server program. It 

35 can therefore run in a standard Windows/Macintosh 
point-and-click office environment, and requires no ad- 
ditional specialized software programming by the user. 
Additionally, other standard or non-standard computing 
environments may support embodiments of the medical 

40 database system 1 00. 

[0026] As illustrated in the embodiment of Figure 1, 
the server computer can access a chart database 13. 
The chart database 13 stores the previously described 
electronic charts corresponding to patients that have uti- 

45 Nzed emergency medical transportation. The server com- 
puter can also access a statistical database 14 to store 
and extract statistical information from data entered dur- 
ing patient encounters. The collected statistics might in- 
clude, for example, average scene and transport times, 

50 number of transport requests per demographic region 
and time of year, average number of advanced proce- 
dures performed by crew members and number of com- 
plications encountered. In addition, the database 14 can 
hold information relating to the average length of time to 

55 process claims by category and payment plan. 

[0027] The server computer 12 can also be linked to 
a regional trauma database 15. The database 15 stores 
information relating to, for example, local trauma centers, 
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emergency medical practice, and other local trauma-re- 
lated information. 

[0028] The dispatch module on the server computer 
12 can be accessed via an interface to a dispatch com- 
puter 20, which might reside, for example, at the dispatch 
centerthat receives the initial call to deploy an emergency 
medical team. The dispatch computer 20 may provide a 
communications interface to the server computer 1 2 so 
that it acts as computer terminal, or it may contain a por- 
tion of the dispatch module. 

[0029] Based on the scene location and needs of the 
patient, the dispatch center might deploy, for example, a 
helicopter 24, airplane 25 or ambulance 26. The dispatch 
computer 20 communicates with software applications 
for collecting information on the patient encounter and 
scheduling and deploying a crew to assist the injured 
patient. Within one embodiment of the medical database 
system 1 00, the helicopter 24, airplane 25 or ambulance 
26 would include a portable computing device ("user de- 
vice") 210 that is used by the emergency medical team 
during the patient encounter. A wireless connection 32 
can be made by the user device 210 to the server com- 
puter 12, via a public network50, for example the Internet, 
a Wide Area Network (WAN), or an Intranet, to update 
the database 14 after data is entered. The user device 
21 0 may include clinical and diagnosis modules to assist 
the emergency medical team in treating the injured pa- 
tient, or may act as a terminal device to communicate 
with these modules on the server computer 1 2. The clin- 
ical and diagnosis modules assist the emergency medi- 
cal team in determining the proper diagnosis and treat- 
ment of the patient. 

[0030] One embodiment of the medical database sys- 
tem 1 00 may also include a billing computer 36 in com- 
munication with the server computer 1 2 via a public net- 
work 50, for example the Internet. The billing computer 
36 interfaces with the server computer 1 2 to run the billing 
module for tracking inventory. The billing module can be 
stored directly on the billing computer 36 or, alternatively, 
stored on the server computer 12 and accessed via the 
billing computer36 overthe public network 50. The billing 
module may be used to track inventory and medical 
equipment. In addition, it may be used during the patient 
encounter for providing billing functions within the med- 
ical database system 100. The billing computer 36 may 
additionally communicate with a printing device 38, for 
example an inkjet printer, laser printer, dot matrix printer, 
or other printing device, to provide printed reports and 
bills to hospitals, patients and medical centers. 
[0031] An administration computer 40 communicates 
with the server computer 1 2 via the public network 50 to 
provide administrative reports. These reports relate to 
the statistical information stored in the statistical data- 
base 1 4. In addition, the administration computer 40 can 
run reports that relate to payroll, inventory, flight training, 
or many other administrative issues. 
[0032] It should be noted that the dispatch computer 
20, user device 210, and billing computer 36 can com- 



municate with the server computer 12 through a variety 
of communications modes and protocols. For example, 
a wireless Local Area Network ("LAN") or cellular network 
may connect the various computers with one another. In 
5 another embodiment, dedicated or dial-up phone lines 
may be used to communicate between the different com- 
puters. 

[0033] Figure 2 is a diagram of top-level VPN system 
components 200 in accordance with one embodiment of 

10 the medical database system 100 of Figure 1. As de- 
scribed in further detail below in relation to Figure 3, the 
user device 210 may consist of one or more types of 
portable computing device configured to communicate 
via various communications modes and protocols. In the 

15 embodiment of Figure 2, the user device 21 0 is config- 
ured to communicate over a public network 50, one ex- 
ample being the Internet. The public network 50 enables 
the user device 210 to communicate with one or more 
VPN server 220 for logging in and accessing the one or 

20 more database servers 1 2 of the medical database sys- 
tem 1 00. The logging in and accessing of the database 
servers 12 is described in further detail below in relation 
to Figure 3. 

[0034] As used herein, the VPN server 220 enables a 

25 secure and encrypted communications link between cer- 
tain nodes on the public network 50. While the nodes can 
communicate with each other, it is virtually impossible 
for other nodes to decipher the meaning of the signals 
or send signals that are believed to be authentic. One 

30 secure communications technology that facilitates such 
a VPN is Secure Sockets Layer ("SSL"). Other secure 
communications technologies may be used as well, and 
although SSL is a transport protocol, other security tech- 
niques that are not transport protocols may be utilized. 

35 The non-SSL techniques may be such that it will quickly 
and efficiently encrypt and likewise decrypt the data that 
is being transmitted via the public network 32. Thus, data 
security and user authentication does not require an ex- 
pensive and geographically limited dedicated private net- 

40 work, but may be accomplished utilizing VPN technology 
via a public network 50 such as the Internet. 
[0035] A VPN server refers to software, hardware, or 
both that secure network communications and authenti- 
cate validity of users in such a way as to minimize the 

45 possibility that it can altered or inappropriately viewed or 
transmitted. A VPN can operate between a number of 
internet-enabled devices. For example, a VPN can run 
on two or more computers that are connected together 
using security technologies such as SSL. In another em- 

50 bodiment, a VPN can operate between a client computer 
and a server computer using security technologies. In 
yet another embodiment, a VPN can additionally operate 
between many client computers and/or many server 
computers. Many types of portable devices can be used 

55 as user devices 21 0 as part of the VPN as well, as de- 
scribed in further detail below in relation to Figure 3. 
[0036] Figure 3 is a diagram of detailed VPN system 
components 300 in accordance with the medical data- 
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base system 100 embodiment of Figures 1 and 2. As 
shown in Figure 3, many user devices 210 and modes 
of data communication 302 may be used to transfer data 
from the transporting vehicle (see part numbers 24, 25 
and 26 in Figure 1 ) to/from the medical database system 
100 via the public network 50. A non-exhaustive list of 
user devices 21 0 that may be used include a laptop com- 
puter, a pen computer, a digitizing pad, a personal digital 
assistant ("PDA"), a wireless device communicating via 
radio frequency ("RF") waves with a radio tower or a sat- 
ellite, or a computer communicating with a satellite via a 
hub 335 and a satellite dish 330. 
[0037] In the embodiment of Figure 3, the user devices 
21 0 may communicate via the public network 50 utilizing 
a number of various modes and protocols of communi- 
cation 302. For example, such modes of communication 
302 include a Universal Serial Bus ("USB"), Firewire, In- 
frared signals, Bluetooth wireless communications, IEEE 
802.2 signals, radio frequency signals such as those of 
frequency 900 megahertz or higher, straight-through and 
crossover Ethernet cables, switched packets or sockets 
transmission, token rings, frame relays, T-1 lines, DS 
connections, fiber optic connections, RJ-45 and RJ-11 
connections, serial pin connections, ultrasonic frequency 
connections, and satellite communications. Other modes 
and protocols of communication 302 are also possible 
and are within the scope of the present invention. 
[0038] In one embodiment, the user device 21 0 com- 
municates via the public network 50 with a network com- 
munications routing device ("router") 336, for example a 
main gateway router, which directs network traffic be- 
tween the appropriate network servers. Examples of 
commercially available network routers 336 include 
those made by Cisco, Linksys, Netgear, Netopia, and 
Hewlett-Packard. The data communications from the us- 
erdevice 21 0 are directed by the router 336 to the medical 
database system 100 via a network hub or switch 340. 
The hub or switch 340 forwards the data communication 
packets to one or more VPN server 220. 
[0039] Current technologies that offer VPN server 220 
capabilities include hardware, software, and a combina- 
tion of hardware and software that function both inde- 
pendently and together with other VPN servers 220. In 
the embodiment of Figure 3, two VPN servers 220 or 
shown as an example, but other embodiments may in- 
clude one VPN server220, while still other embodiments 
may include more than two VPN servers 220. Vendors 
may package VPN capabilities into a device termed an 
"appliance," which is typically a dedicated hardware de- 
vice configured with embedded security policies. VPN 
vendors and manufacturers include, for example, Nortel, 
Checkpoint, Nokia, Sun Microsystems, Cisco, Netopia, 
Compaq, IBM, Hewlett-Packard, Watchguard, Linksys, 
Netgear, and Lucent. Such VPN systems provide system 
administrators the ability to set security policies and rules 
as to the rights each user and each application will be 
allowed on the servers of the medical database system. 
[0040] In one embodiment, the VPN servers 220 pro- 



vide encryption and decryption keys to a user, so that 
the user's data communications are secured using vari- 
ous encryption/decryption algorithms, including, for ex- 
ample, DES, 3DES, MD5, SHA, 40-bit, 56-bit, 128-bit, 
5 168-bit, and other types of encryption/decryption algo- 
rithms. In this way, the user establishes a secure com- 
munication to the servers of the medical database system 
1 00, using one or a redundant array of VPN servers 352. 
Further, to increase system up time and reliability, a fail- 
le safe protocol can be implemented to achieve a fail over 
configuration by connecting redundant communications 
313, 314. In such a configuration of VPN servers 352, if 
one VPN server 352 fails, one or more of the other VPN 
servers 352 undertakes the workload, so that the user is 
15 likely not even aware that a failure has occurred. 

[0041] One or more firewalls 352 may be configured 
in order to secure the connection beyond the router 336 
by preventing external network access to the servers 
comprising the medical database system 100 by non- 
20 authorized devices and/or users on the public network 
50. The firewal Is 352 may be a separate hardware device, 
or may be either hardware and/or software that is incor- 
porated into the VPN servers 220. The VPN servers 220 
authenticate the users that login to the medical database 
25 system 1 00 and allow only those authorized users access 
to the medical database system 1 00 servers through the 
firewalls 352. 

[0042] Data communications that the firewalls 352 in 
conjunction with the VPN server 220 allow to pass 

30 through to the servers of the medical database system 
1 00 are forwarded by a hub orswitch device 340 to either 
a terminal server 342 or to a database server 12. The 
embodiment of Figure 3 shows two terminal servers 342 
and two database server 12, but more or fewer terminal 

35 servers 342 and more or fewer database servers 12 may 
also be used in further embodiments. In addition, the 
number of terminal servers 342 may be different than the 
number of database servers 1 2 in certain embodiments. 
The terminal servers 342 and/or database servers 12 

40 may be configured as aserverfarm. Aserverfarm refers 
to a pool or multitude of servers functioning together to 
perform common server functionality. In one embodi- 
ment, an authorized user may initiate two types of con- 
nections to the medical database system 1 00, a terminal 

45 server request or a direct database server request. Such 
server farms are able to perform load balancing or fail- 
safe switching of servers should one or more become 
non-operational to accomplish redundancy or system ef- 
ficiency. 

50 [0043] In one embodiment, a direct database server 
request may be made by the user to connect the user 
device 210 to the database server 1 2. The database 356 
and database server 12 operate in a client/server rela- 
tionship, such that in order to access the database, the 

55 user establishes a client connection to the database serv- 
er 12. Database 356 access is accomplished by making 
database requests to the database server 12 over a se- 
cure, password protected, and dedicated channel of 
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communication. In cases where the communications 
channel supports a direct connection, i.e. low communi- 
cations latency, sufficient data communication band- 
width, or strong system configuration, the user devices 
21 0 can communicate directly with the database servers 
12. 

[0044] The database 356 and database server 1 2 con- 
tain the operating system components to run the core 
system, for example, Macintosh, Windows, Linux, Unix, 
and other operating systems. In one embodiment of the 
medical database system 100, the database server 12 
and database 356 utilize a database that is ODBC, Se- 
quel, Sybase, 4D, and Oracle compliant such that it can 
integrate with a majority of these operating systems and 
other database systems. The data may be stored on a 
main database server 1 2, but may also be configured to 
mirror and fail-safe over to another database system, 
achieving redundancy, system efficiency, and backup ef- 
ficiency, among other benefits. 

[0045] Current database 356 technologies include 
commercially available brand and product names, for ex- 
ample, Oracle, 4D, Sequel Server, Sybase, Filemaker, 
Access, Cold Fusion, FoxPro, and other database sys- 
tems. Such databases function as relational databases 
that allow for querying and database development on 
multiple planes, and also for granting user specific ac- 
cess to regions of the database. These databases also 
typically include client software applications that commu- 
nicate with the database 356. The client software appli- 
cations are installed on the user workstation and create 
a channel of communication with the user and the data- 
base 356. 

[0046] However, in other cases, the communications 
channel does not support a direct connection, sothe user 
device 21 0 communicates with the database servers 12 
through the terminal servers 342. A terminal server re- 
quest may be made by the userto connect the userdevice 
210 to the terminal server 342, such that the terminal 
servers 342 deliver a screen to the user to control a re- 
mote server. The terminal servers 342 allow multiple us- 
ers to connect to run a heterogeneous portfolio of appli- 
cations, providing the user with what appears to be a 
personal and individual worksession. Thus, the user may 
remotely control the terminal servers 342 to perform the 
communications processing with the database servers 
1 2 as described above. The terminal server 342 may be 
many various types of devices running various types of 
operating systems, for example Microsoft servers, Unix 
servers, BSD, Apple Macintosh, Linux, and other com- 
puter systems and operating systems. Some examples 
of common enterprise level software platforms in current 
existence and use include, for example, Microsoft Ter- 
minal Services using the Remote Desktop Protocol 
("RDP"), Cisco PIX Firewalls, PCAnywhere, Timbuktu, 
VNC, and Citrix Metaframe software applications. In a 
further embodiment, a fax machine 346 may optionally 
be connected to the database servers 356, enabling the 
database servers 356 to send faxes, for example, when 



a paper invoice is required to be sent. 
[0047] Figure 4 is a block diagram of client applications 
of the user device 210, VPN server 220, and terminal 
server 342 components as shown in the embodiment of 

5 Figure 3. In this embodiment, the user devices 210 in- 
clude client applications for the terminal server user ap- 
plication 41 0 and database client application 41 6. As de- 
scribed above in relation to Figure 3 and below in relation 
to Figure 5, one embodiment of the user devices 210 

10 only includes one orthe other of the terminal server user 
application 410 and database client application 416, de- 
pending on whether the user connects to the database 
servers 1 2 directly or connects through the terminal serv- 
ers 342. However, other embodiments may include both 

15 of these applications 41 0, 41 6. In one embodiment, the 
database client application 416 is the Citrix client Meta- 
frame, or it may additionally be Nfuse, which allows the 
use of a web browser. 

[0048] The user devices 210 additionally include op- 
20 erating system software 420, for example Macintosh, 
Windows, Linux, Unix, or other computer operating sys- 
tems. The user devices 210 may additionally include a 
browser application 426 for accessing the public network 
50 such as the Internet and allowing the display of and 
25 interaction with various websites accessible via the In- 
ternet. Forexample, several such commonly used brows- 
er applications are Microsoft Internet Explorer and Net- 
scape Navigator. 

[0049] I n the embodiment of Figure 4, the VPN servers 

30 220 include client applications for the firewall 436 and 
VPN applications 440, which may both be provided by a 
single application, for example Checkpoint VPN1. The 
VPN application 440 utilizes encryption keys 430 and is 
controlled by policies and privileges 456 that are set up 

35 by someone with system administrator level privileges. 
For example, the policies and privileges 456 include 
specifying which ports are authorized to send data in what 
direction (e.g. input, output, or both), and specifying 
which applications are authorized to access which ports. 

40 The VPN servers 220 additionally include operating sys- 
tem software 446, as described above in relation to the 
user device 21 0 of Figure 4. The VPN servers 220 addi- 
tionally include Local Area Network ("LAN") application 
software, forexample TCP/IP, UDP, IPS/SPX, NetBeui, 

45 NetBios, XML, and AppleTalk, for file sharing, printing, 
internal server communications, and other LAN network 
capabilities. 

[0050] In one embodiment, the terminal servers 342 
include the database client application 41 6 as described 

50 above in relation to the user device 21 0 of Figure 4. The 
terminal servers 342 additionally include a terminal serv- 
er application 470, an operating system software 476 as 
described above in relation to the user device 21 0 of Fig- 
ure 4, and the LAN application 460 as described above 

55 in relation to the VPN server 220 of Figure 4. 

[0051 ] While the embodiment of Figure 4 shows a spe- 
cific example of the client applications that may be in- 
cluded in the user devices 210, VPN servers 220, and 



7 



13 



EP 1 990 748 A1 



14 



terminal servers 342, other embodiments utilizing other 
client applications in various configurations are also with- 
in the scope of the present invention. As Figure 4 illus- 
trates one embodiment of the devices and servers of the 
medical database system 1 00, the present invention is 
not limited to this embodiment but also includes other 
embodiments as well. 

[0052] Figure 5 is a flowchart of database access op- 
erations of the medical database system 100 in accord- 
ance with the embodiments of Figures 1 -3. At stage 51 0, 
the user initiates the login connection for a VPN client 
key. At stage 51 6, the VPN client key request is tagged 
and encapsulated with information and sent for authen- 
tication within the VPN server 220. The VPN server 220 
includes a decision process mechanism forf unneling ap- 
plications and users to the predetermined authorized ar- 
eas within the public network 50. The VPN server 220 
additionally blocks those activities that are not authorized 
within the policies as set by the system administrator. 
Another function of the VPN server 220 is to make the 
user authentication determination shown at stage 520. 
At decision stage 526, the system either allows success- 
ful access to the database system, or denies access to 
the requesting user. Upon such a denial of access, at 
stage 530 the system administrator is optionally notified 
of the denial of access to the user. The system may utilize 
a variety of ways of notifying the system administrator, 
such as via paging, fax, email, audio/visual alerts, entry 
into a log file, or other ways of notification. The user may 
attempt the login and authentication process again at 
stage 51 0. 

[0053] If the user authentication at stage 526 is instead 
successful, the user is notified of successful VPN access. 
A notification may additionally be sent to the system ad- 
ministrator, for example, via email, fax, audio/visual 
alerts, log file entry, or other notification means. At stage 
536, the user logs in to the VPN server 220 and further 
communications utilize a dedicated, secure, and encrypt- 
ed channel. Private VPN level connections are designed 
andconfiguredwithahigh level of security and encryption 
to maintain data confidentiality. The VPN encapsulates 
the data and creates encryption around each packet of 
information with a variety of different encryption schemes 
that are enforced by the database server 1 2 and the da- 
tabase 356. In the current technology, standard encryp- 
tion uses 40 bit, 56 bit, 128 bit, and 1 68 bit keys. Trends 
in the technology indicate that in the future these degrees 
of encryption will be enhanced, or may possibly use a 
combination of levels to maximize efficiency and encod- 
ing. 

[0054] At optional stage 540, the user may log in to the 
terminal server 342 to communicate with the database 
server 1 2 via the terminal server 342. However, at stage 
546 the user may also elect to log in directly to the data- 
base server 12 and bypass the terminal server login at 
stage 540. Having logged in to the database server 12, 
the database server 12 determines, based on the au- 
thentication level, the access thatthe userwill be allowed, 



which in turn governs which of the following operations 
the user may perform. At stage 550 the user may elect 
to perform administrator operations, assuming the user 
has the required authentication level. At stage 556 the 

5 user may elect to perform billing operations, again as- 
suming the user has the required authentication level. At 
stage 560 the user may elect to perform clinical opera- 
tions, assuming the user has the required authentication 
level. At stage 566 the user may elect to perform dispatch 

10 operations, once again assuming the user has the re- 
quired authentication level. In other embodiments, the 
users may elect to perform other medical database sys- 
tem operations they are authorized to perform that are 
not shown in the embodiment of Figure 5. 

15 [0055] At decision stage 570, the user may elect to log 
off the medical database system 100 and end the oper- 
ations shown in Figure 5, or alternatively the user may 
elect to remain logged in to the system and elect another 
operation to perform. 

20 [0056] Figure 6 is a diagram of one example of a da- 
tabase configuration layout 600 in accordance with an 
embodiment of the medical database system 1 00. In this 
embodiment, a medical database record, which may be 
stored in the chart database 13 shown in Figure 1, in- 

25 eludes fields for medical condition 610, patient informa- 
tion 620, patient location 630, transportation destination 
640, means of transportation 650, and estimated time of 
arrival ("ETA") 660. In other embodiments, the medical 
records may include more orfewer fields than are shown 

30 in the embodiment of Figure 6. In addition, the databases 
may include more or fewer record entries than shown in 
the embodiment of Figure 6. 

[0057] The database configuration layout 600 example 
shown in Figure 6 may contain confidential patient med- 

35 jcal information. Such database records are securely 
transferred between the database 356 and the various 
servers of the medical database system 1 00 as described 
above in relation to the VPN system in Figures 3 and 5. 
The patient information is essentially safe from intercep- 

40 tion by unauthorized users on the public network 50 in a 
system as described herein. 

[0058] While the above detailed description has 
shown, described, and pointed out novel features of the 
invention as applied to various embodiments, it will be 

45 understood that various omissions, substitutions, and 
changes in the form and details of the device or process 
illustrated may be made by those skilled in the technology 
without departing from the spirit of the invention. The 
scope of the invention is indicated by the appended 

50 claims ratherthan by theforegoing description. All chang- 
es that come within the meaning and range of equiva- 
lency of the claims are to be embraced within their scope. 



1 . A secure integrated emergency medical transporta- 
tion database system (100), comprising: 
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a medical emergency database (1 2) comprising 
at least clinical encounter information, patient 
demographic data and transport information as 
electronic protected health information; 
a billing module (36) configured to access the 
medical emergency database and generate a 
bill for each medical emergency requiring trans- 
port; and 

a secure communications application (440) con- 
figured to allow secure access to the medical 
emergency database and/or billing module by a 
plurality of authorized users via a public network 
(50), wherein the secure access comprises 
technical security measures to protect against 
unauthorized access to the electronic protected 
health information during transmission over the 
public network so that data indicative of a med- 
ical emergency is securely stored in the medical 
emergency database from a location in the field 
that is remote from a health service facility. 

2. The system of Claim 1 , wherein the secure commu- 
nications application is additionally configured to al- 
low the secure transfer of medical data via the public 
network. 

3. The system of Claim 1 , wherein the secure access 
is compliant with the European Standards on Confi- 
dentiality and Privacy in Healthcare. 

4. The system of Claim 1 , wherein the secure access 
protects against a risk of interception during elec- 
tronic transmission of the health information. 

5. The system of Claim 1 , wherein the secure access 
is compliant with European Union patient privacy 
standards. 

6. The system of Claim 1 , wherein the secure commu- 
nications application secures communications via 
the public network. 

7. The system of Claim 1 , wherein the secure commu- 
nications application uses secure sockets layer. 

8. The system of Claim 1 , wherein the secure commu- 
nications application includes a virtual private net- 
work (220). 



nications application authenticates validity of a one 
of the plurality of authorized users. 

12. The system of Claim 1, wherein the secure commu- 
5 nications application includes a dedicated, secure 

and encrypted channel. 

13. The system of Claim 1, wherein the transport infor- 
mation comprises information obtained about the 

10 transport after first contact by medical transport per- 
sonnel. 

14. The system of Claim 1, wherein the transport infor- 
mation is associated with the clinical encounter in- 

15 formation by at least patient pickup data. 

15. The system of Claim 1, additionally comprising a 
portable computing device (21 0) used by emergency 
medical personnel to wirelessly access a public net- 

20 work in realtime while at the patient pick-up location 
or during a transport of an emergency medical serv- 
ices patient. 

16. The system of Claim 15, wherein the secure com- 
25 munication application is associated with the com- 
puting device. 

17. The system of Claim 15, wherein the portable com- 
puting device is used by emergency medical person- 

30 nel inside an emergency transport vehicle 
(24,25,26). 

18. The system of Claim 1, wherein the transport infor- 
mation comprises vehicle tracking information in- 

35 eluding segmental flight time for each transport seg- 
ment. 

1 9. The system of Claim 1 , wherein the technical security 
measures minimize accessto inappropriate informa- 

40 tion based on job requirements. 

20. The system of Claim 1 , wherein the field location is 
at a location between two health service facilities that 
are the source and destination of the transport. 

45 

21. A method of providing access to a secure integrated 
emergency medical transportation database system 
(100), comprising: 

collecting at least clinical encounter information, 
patient demographic data and transport infor- 
mation as electronic protected health informa- 
tion for each of a plurality of medical emergency 
incidents requiring transport into a medical 
emergency database (12); 
accessing the medical emergency database; 
generating a bill for each medical emergency 
incident accessed; and 



9. The system of Claim 1 , wherein the secure commu- 50 
nications application includes encryption and de- 
cryption algorithms. 

10. The system of Claim 1 , wherein the secure commu- 
nications application includes encryption and de- 55 
cryption keys (430). 

11. The system of Claim 1 , wherein the secure commu- 
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securing access to the medical emergency da- 
tabase and/or billing information by a plurality of 
authorized users via a public network (50), 
wherein securing access comprises using tech- 
nical security measures to protect against un- 
authorized access to electronic protected health 
information during transmission over the public 
network so that data indicative of a medical 
emergency is securely stored in the medical 
emergency database from a location in the field 
that is remote from a health service facility. 

22. The method of Claim 20, further comprising securing 
the transfer of medical data via the public network. 

23. The method of Claim 20, wherein securing access 
is compliant with the European Standards on Confi- 
dentiality and Privacy in Healthcare. 

24. The method of Claim 21, wherein securing access 
comprises protecting against a risk of interception 
during electronic transmission of the health informa- 
tion. 

25. The method of Claim 21, wherein securing access 
is compliant with European Union patient privacy 
standards. 

26. The method of Claim 21, wherein securing access 
comprises securing communications via the public 
network. 

27. The method of Claim 21, wherein securing access 
comprises using secure sockets layer. 

28. The method of Claim 21, wherein securing access 
comprises using a virtual private network (220). 

29. The method of Claim 21, wherein securing access 
includes using encryption and decryption algorithms. 

30. The method of Claim 21, wherein securing access 
includes using encryption and decryption keys (430). 

31. The method of Claim 21, wherein securing access 
includes authenticating validity of a one of the plu- 
rality of authorized users. 

32. The method of Claim 21, wherein securing access 
comprises using a dedicated, secure and encrypted 
channel. 

33. The method of Claim 21, wherein the transport in- 
formation comprises patient pickup data and seg- 
mental flight time, and is used for billing. 

34. The method of Claim 21 , wherein the collecting com- 
prises wirelessly collecting the electronic protected 



health information by emergency medical personnel 
via a public network while at the scene of the patient 
encounter or during transport of an emergency med- 
ical services patient. 

5 

35. The method of Claim 34, wherein the wirelessly col- 
lecting comprises using a portable computing device 
(210) inside an emergency transport vehicle 
(24,25,26). 

10 

36. The method of Claim 21, wherein the transport in- 
formation comprises vehicle tracking information in- 
cluding segmental flight time for each transport seg- 
ment. 

15 

37. The method of Claim 21 , wherein the field location 
is at a location between two health service facilities 
that are the source and destination of the transport. 
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